home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000091_owner-urn-ietf _Thu Oct 24 05:10:14 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  7KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA08944 for urn-ietf-out; Thu, 24 Oct 1996 05:10:14 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA08939 for <urn-ietf@services.bunyip.com>; Thu, 24 Oct 1996 05:10:12 -0400
  3. Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA24239  (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 05:09:38 -0400
  5. Received: from [192.71.220.137] (zap.swip.net [192.71.220.137])
  6.         by nic.cafax.se (8.8.2/8.8.2) with ESMTP
  7.         id LAA00967;
  8.         Thu, 24 Oct 1996 11:09:34 +0200 (MET DST)
  9. X-Sender: m-3329@mailbox.swip.net
  10. Message-Id: <v03007802ae94cf233d55@[192.71.220.137]>
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset="iso-8859-1"
  13. Content-Transfer-Encoding: quoted-printable
  14. Date: Thu, 24 Oct 1996 11:08:19 +0200
  15. To: urn-ietf@bunyip.com
  16. From: Patrik Faltstrom <paf@swip.net>
  17. Subject: [URN] UNICODE or not UNICODE?
  18. Cc: splinter@bunyip.com
  19. Sender: owner-urn-ietf@services.bunyip.com
  20. Precedence: bulk
  21. Reply-To: Patrik Faltstrom <paf@swip.net>
  22. Errors-To: owner-urn-ietf@bunyip.com
  23.  
  24. Terry wrote
  25. > - why care?  the NSS is supposed to be opaque
  26. > - does this imply that a) NSSs should be formed originally
  27. >   in Unicode, or that b) NSSs in other coded character sets
  28. >   must be translated/transliterated into Unicode in forming
  29. >   URNs, or c) something else?
  30.  
  31. The problem with not defining a character set is that it will
  32. be impossible to do any comparison between two URNs. We need to have
  33. some ability to do comparisons, and the only reasonable way of doing that
  34. is to use _one_ character set.
  35.  
  36. To answer the second question, you have to have a urn in a different
  37. character set in some cases, for example in a client which does not
  38. use UNICODE. You then have to do translation.
  39.  
  40. What we did in Digger, the Whois++ server Bunyip has, was using the
  41. rules for comparison (decomposition + sorting) and translation rules
  42. that the UINCODE consortium have defined.
  43.  
  44. The UNICODE tables include for each character one kind of equivalence
  45. which is the rule for decomposition of that code point in UNICODE
  46. into more than one other code point. One example, the letter '=C4'.
  47.  
  48. In UNICODE, this character is defined as:
  49.  
  50. 00C4;LATIN CAPITAL LETTER A WITH DIAERESIS;Lu;0;L;0041 0308;;;;N;
  51.      LATIN CAPITAL LETTER A DIAERESIS;;;00E4;
  52.  
  53. One can here see that the codepoint, U+00C4, is equivalent to U+0041
  54. followed by U+0308. One can also see that the lower case version of this
  55. character is U+00E4 (among other things).
  56.  
  57. When comparing two strings, and one of them include "U+00C4"
  58. and the other one the sequence "U+0041"+"U+0308" these strings
  59. should be considered equal in the sense of the UNICODE spec.
  60.  
  61. Note that I am not talking about ISO-10646 here, as I am not at all
  62. familiar with what parts of this is included in the 10646 spec. This
  63. is UNICODE 2.0 we are talking about!
  64.  
  65. When comparing strings, one have to do decomposition, and the definition
  66. of decomposition is:
  67.  
  68. >Decomposition.
  69. >       (1) the process of separating or analyzing a text element into
  70. >           component units. These component units may not
  71. >           have any functional status, but may be simply formal units, i.e.=
  72. ,
  73. >           abstract shapes; (2) the process of replacing a
  74. >           code element with multiple code elements, which, together,
  75. >           represent the original code element in some
  76. >           manner, e.g., the shapes associated with the resulting
  77. >           code elements may combine to form the shape associated
  78. >           with the original code element.
  79.  
  80. This means that before comparing the strings that include "U+00C4"
  81. and "U+0041"+"U+0308", all code points have to be decomposed into its
  82. maximal decomposition possible. I.e. "U+00C4" have to be changed to
  83. "U+0041"+"U+0308", and these have to be sorted (i.e. one can know
  84. from the code tables that "U+0041" is to be before "U+0308" in
  85. a composed character).
  86.  
  87. THEN we do the comparison codepoint by codepoint.
  88.  
  89. If we wanted to do case insensitive matching, we use the information
  90. from the UNICODE consortium about what is a lower case character.
  91.  
  92. Terry continues:
  93.  
  94. >When I translate that 8859-6 name into Unicode I have more
  95. >than one possible outcome (depending on whether I keep it
  96. >simple, using 0621--064A or use Unicode code points that
  97. >include diacritical marks
  98.  
  99. If one have a look at the UNICODE tables, one can see that for example
  100. U+0621 is a final form of a whole series of other glyphs,
  101. for example
  102.  
  103. =46E80;ARABIC LETTER HAMZA ISOLATED FORM;Lo;0;R;<isolated> 0621;;;;N;
  104.      GLYPH FOR ISOLATE ARABIC HAMZAH;;;;
  105.  
  106. which is the special glyph used in isolated form. You see that U+FE08
  107. should be equivalent to U+0621, so when using the decomposition
  108. rules before comparing strings, U+FE80 and U+0621 are considered
  109. equivalent.
  110.  
  111. This is exactly why decomposition is needed.
  112.  
  113. >or use Unicode code points that
  114. >indicate glyph variants of a letter, such as 06AA, "Arabic
  115. >Letter Swash Kaf," which is lexically the same as 0643,
  116. >"Arabic Letter Kaf`" or specify some ligatures).
  117.  
  118. I don't know Arabic, but I am just following the rules that
  119. UNICODE consortioum have set up, and according to these
  120. rules, U+06AA and U+0643 is not equivalent characters
  121. when comparing:
  122.  
  123. 06AA;ARABIC LETTER SWASH KAF;Lo;0;R;;;;;N;ARABIC LETTER SWASH CAF;;;;
  124. 0643;ARABIC LETTER KAF;Lo;0;R;;;;;N;ARABIC LETTER CAF;;;;
  125.  
  126. I am not arguing if this descision by the UNICODE consortium
  127. was correct or not, but _someone_ that they trusted must have
  128. told them these are different characters.
  129.  
  130. >Say
  131. >I can have outcomes A, B, and C, all of them legitimate
  132. >representations of my 8859-6 name in Unicode.  Are
  133. >urn:mynamespace:A, urn:mynamespace:B, and urn:mynamespace:C
  134. >equivalent?  Once the URN is passed to the resolver, is
  135. >it contemplated that the resolver will translate the URN's
  136. >NSS back into 8859-6?
  137.  
  138. When mapping to/from ISO-8859-6 and UNICODE, the consortium
  139. have a table which one should use. In that table I can
  140. read out that U+0643 in ISO-8859-6 is 0xE3, but that
  141. U+06AA is missing from ISO-8859-6. A client have because of
  142. this know that UNICODE is what the URN is specified in,
  143. and do appropriate mappings -- i.e. if a URN have U+06AA
  144. as one of the characters, that URN can not be entered
  145. directly on a client working in ISO-8859-6 (and neither
  146. on a client working in ISO-8859-1 or US-ASCII).
  147.  
  148. In this case %encoding can be used.
  149.  
  150.     Patrik
  151.  
  152.  
  153. --------------------------------------------------------------------
  154.    Senior Researcher, Tele2/SwipNet     Stockholm, Sweden
  155.    paf@swip.net                         Phone: +46-8-56264000
  156.    urn:inet:urn.paf.se
  157.  
  158.    In theory, there's no difference between theory and practice,
  159.    but in practice, there is.
  160.  
  161.